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UNIX on the 


by Gary L. Grebus, K8LT 


Probably the most frequent com- 
plaint hams have about running TCP/ 
IP is the size of the software. The 
KASQ package has nearly outgrown 
the 640K memory limit under DOS. In 
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the future, large “hub” stations may 
need to switch to alternative hardware 
and software in order to provide the 
desired range of services. Since | use 
the UNIX operating system in my 
home computing, I’ve been exploring 
it as an alternative for AMPRnet 
systems. 


In theory, UNIX should be the ideal 
operating system for an AMPRnhet 
node. Most TCP/IP development was 
originally done on UNIX systems. 
There is an abundance of public 
domain software for handling the 
usual applications, such as mail trans- 
fer. Also, UNIX clients and servers are 
usually implemented as separate pro- 
grams, reducing memory require- 
ments and easing software main- 
tenance. However, not all versions of 
UNIX are equal, and none directly 
support the protocols and hardware 
needed for the radio environment. The 
remainder of this article describes 
some approaches to putting a UNIX 
based system on the AMPRnet, and 
my experiences with them. 


o The porting approach 


The first system | put on the 
AMPRhnet was an AT&T 7300 UNIX- 
PC. The developers of this machine 
did a brilliant job of putting UNIX into a 
“personal computer” sized package, 
based on a 68010 processor. The 
system was somewhat a commercial 
failure, but has become popular in the 
hobbyist market and is often available 
at prices in the $500-$1000 range. 
The UNIX-PC runs a version UNIX 
based on AT&IT’s early System V 
releases. Since TCP/IP software isn’t 
readily available for this machine, | 
chose to adapt KA9Q NET (and later 
NOS). 


Porting NOS is an approach that 
can be used to put almost any UNIX 
system on the AMPRnet. SMOGRV 
did the initial work, adapting NOS to 
run under System V UNIX on 80386 
systems, and Berkeley (BSD) UNIX 
on Sun systems. Porting to the UNIX- 
PC however, required some additional 
pain. First, NOS was written assuming 
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an ANSI C compiler. Although con- 
ditional compilation is included for 
non-ANSI compilers, it is somewhat 
incomplete and minor changes are 
required in many modules in order to 
compile with the UNIX-PC compiler. 
NOS also requires a timer that can 
tick (interrupt) at sub-second intervals. 
Since the UNIX-PC lacks such a 
facility, a simple device driver was 
written to provide access to the 
operating system’s internal timers. 
Problems also surfaced in the NOS 
multi-tasking code when the NOS 
process was pre-empted while execut- 
ing critical sections of the task sche- 
duler. Finally, some problems related 
to 68000 data alignment rules were 
found. 


One undisputable advantage of 
using NOS is that it already 
supports the AX.25, KISS, 
NET/ROM and other protocols 
needed for packet radio. 


It also provides the normal AMPR- 
net user environment (e.g. the mail- 
box, keyboard-to-keyboard _ telnet). 
There are however, some noticeable 
drawbacks. The main one is that NOS 
consumes considerable CPU time in 
handling the timer driven events. If the 
version of UNIX lacks a way to wait on 
multiple read requests (as is the case 
on the UNIX-PC), then even more 
CPU time must be expended polling 
each interface for incoming charac- 
ters. | also believe that network perfor- 
mance is impaired because the avail- 
able timer resolution and accuracy 
Causes errors in measuring backoff 
and round-trip times. 


Another disadvantage is that all of 
the client and server code is still 
resident in a single program. This 
makes software maintenance more 
difficult, and makes it impossible to 
directly use any of the public domain 
applications written for the normal 
UNIX TCP/IP environment. To par- 
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tially address this problem | added a 
“utility” server to NOS. This server 
would respond to a _ connection 
request by forking a process running 
whatever program was defined for the 
particular TCP port number. The utility 
server would communicate data to 
and from the process via pipes. While 
there are limitations in using pipes, the 
mechanism worked well enough to 
support a server which maintained a 
simple database. 


o A hybrid approach 


When NOS is running under a 
multi-tasking operating system, the 
NOS multi-tasking facility is really 
redundant. Anders’ Klemets, 
SMOGRV, developed a special ver- 
sion of NOS called netnix which better 
fits the UNIX environment. In netnix, 
the clients and servers are split out 
into separate programs, leaving 
behind only the core network code. 
The applications communicate with 
the network process using a special 
version of the NOS socket routines. 
The socket routines use the _inter- 
process communication and shared 
memory facilities of System V UNIX to 
pass the routine parameters into and 
out of the network process. While | 
haven’t explored this alternative, it 
seems more attractive than plain NOS 
under UNIX. It is however largely 
experimental. It is based on an early 
version of NOS, and is only a partial 
implementation. Some significant pro- 
gramming is probably still required to 
have all of the NOS features available. 


o The native approach 


My current UNIX system is an 
80386 based PC clone. The generally 
available versions of UNIX for the 
80386 are System V based, and most 
offer some form of TCP/IP support. 
Since | wanted to avoid the disadvan- 
tages described above, | chose to try 
to use this native TCP/IP support to 
connect to the AMPRnet. 


The first difficulty to be overcome 
was that commercial TCP/IP imple- 
mentations support hardware for Eth- 
ernet and SLIP, but not KISS TNC’s 
or DRSI boards. The quickest solu- 
tion, and the one | chose, was to SLIP 
link the UNIX system to a stripped- 
down PC running NOS. The PC needs 
only a single floppy drive. Even the 
monitor and keyboard could conceiv- 
ably be removed once the configu- 
ration had been set up. Although this 
approach adds hardware expense, it 
saves considerable effort. It avoids the 
need to add AX.25 support and spe- 
cial device drivers to the UNIX sys- 
tem. All the protocols and hardware 
supported by NOS are immediately 
available. Also, some character pro- 
cessing overhead is potentially offloa- 
ded from the UNIX system. Someone 
who wishes to try the all-software 
approach should refer to the paper by 
N1DMM for a description of the effort 
involved [1]. 


The other major variable is the 
choice of which UNIX system to buy. 
There are several companies which 
sell UNIX for 80386 based systems, 
with varying pricing and packaging. | 
purchased the most economically pri- 
ced product, ESIX System V/386 Rev 
D from ESIX Systems Inc. While this 
is a reasonable UNIX product overall, 
the TCP/IP support bundled with it is 
particularly poor for use on the AMPR- 
net. The principal deficiency is that the 
TCP implementation does not dynami- 
cally adjust retransmission times 
based on measured round-trip times. 
The code appears tuned for Ethernet 
timings, and may retransmit a packet 
multiple times before the there is any 
chance that the receiver could res- 
pond. It also frequently encounters 
timeouts when dealing with slow radio 
links and widely varying round-trip 
times. As a result, my system is 
reachable on the AMPRnhet, but not 
reliably so. A number of socket level 
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FROM THE PRESIDENT: 


The first thing I’d like to do in this issue is to clarify what 
| said in the last installment of “From the President”! The 
rush to get these notes out before the press “deadline” 
precluded me from explaining fully what the different 
membership levels are for the N.E. TCP Association (or at 
least this is the excuse I'll use ...hi.) Foremost let me say if 
you paid $12.00 to subscribe to the NE TCPer you *are* a 
member of the Association! If you paid $24.00 you're 
considered a “*voting* member. Either way, consider 
yourself directly involved with the Association and a key 
player. Non voting members can best contribute in the way 


of submitting articles and other input relating to TCP/IP in: 


your area to the Editor. Of course if you’re a ‘voting 
member, direct participation by way of attending the 
NETCPA meetings and volunteering for *active* duty will 
benefit the Association and TCP/IP in general. Murphy 
struck twice in my last column in that | made what | 
consider a “typo”. Remember the line “There is no 
amprnet with you!”? Well as you have already no doubt 
surmised, it was suppose to read: “There is no amprnet 
withOUT you!” An honest mistake, but a mistake non- 
the-less, so here it is, a full apology and correction. You 
can imagine how | felt when | discovered this mistake after 
N1GCR (the Editor) told me: “Well the TCPer’s finally in 
the mail!” My response was “Oh boy, Ill have to wait until 
next issue to clarify my mistakes!”. The moral of the story 
being: Don’t wait until press time to complete “your” article! 
This time I’ve started typing before the April 6 NETCPA 
meeting. I’m not taking chances waiting until the last 
minute ever again (if | can help it that is.) 


“Reproduction of articles appearing in the NE TCPer 
is permitted as long as credit is given to the author 


and to the The NE TCPer.”’ 


Mz O22] Wo, Cea 


- DON’T YOU WAIT 
EITHER! - 


If you have a story or article you 
even think maybe of interest to 
fellow IPer’s why not submit it for 
publication? What are you waiting 
for a written invitation? If so, then 
consider this it! | bet there is an IPer 
somewhere in the world having the 
same problem(s) you have had in 
the past with your little segment of 
the amprnet, and they’d love to know 
how you handled things. What about 
all the experimenting going on with 
the high speed modems and radios? 
Most of the packet world is waiting 
for manufacturing standards, but 
there could be someone reading this 
that has a better way of doing 
things. Is that person you? If so, 
please don’t keep it a secret, the 
world is waiting for your help! If you 
can’t reach me or NiCGR via the 
amprnet, don’t get discouraged, 
send your text along (as an ASCII 
document) in the form of a 3.5” 720k 
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SUBSCRIBE TO THE 
NEW ENGLAND TCPer 
Yes... want to Know more about 
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NAME 
CALL 

ADDRESS 

STATE ZIP 

(1) 6ISSUES(1 YR) FOR ONLY $12.00 
(] 12 ISSUES (2 YRS) FOR ONLY $22.00 
1) 18 ISSUES (3 YRS) FOR ONLY $32.00 
Send to: The NE TCPer 


252 Stow Rd. 
Harvard, MA 01451 
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features are also lacking, for example 
raw sockets and access to the ICMP 
protocol. 


The ESIX TCP/IP support is imple- 
mented on top of the System V native 
networking facility called STREAMS. 
As a consequence, the programming 
interface is based on STREAMS TLI 
(Transport Level Interface) rather than 
on Berkeley-style sockets. ESIX in- 
cludes a library of routines which 
partially emulate the Berkeley socket 
calls, but the differences are large 
enough to be painful. Supported pro- 
tocols include FTP, TELNET, SMTP, 
and RIP. Some useful facilities like 
inetd, finger, ping, and a nameserver 
are missing. 


With the exception of ping, | have 
been able to get at least partially 
functioning replacements by 
porting the publically available 
Berkeley code. 


Some additional work is probably 
desireable to provide an “AMPRnhnet 
friendly” environment. For example, 
telnet connections from the AMPRnet 
might be automatically logged into a 
mailbox-like program rather than 
receiving the normal UNIX login 
prompt. Or finger might be enhanced 
to allow for “canned” messages rather 
than just information about logged in 
users. 


Despite my experiences so far, | 
think the “native TCP/IP” approach is 
a good one. Although I’ve been thwar- 
ted by a poor choice of UNIX soft- 
ware, | think the ease of programming 
and improved performance will out- 
weigh the disadvantages of the “por- 
ted NOS” approach. Other TCP/IP 
packages, for example the one from 
Interactive Systems, appear to be 
much more complete and may be 
better behaved. Also, vendors have 
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begun to introduce products based on 
UNIX System V Release 4. One of the 
goals of this release is to merge 
Berkeley features with System V, so 
perhaps network support will be im- 
proved in the near future. 


o The other native 
approach 


One other possibility for using the 
“native TCP/IP” approach is to obtain 
hardware capable of running real BSD 
UNIX or its derivatives. BSD Release 
4.3 includes what is usually con- 
sidered the benchmark TCP/IP imple- 
mentation and is capable of dealing 
with the latencies and congestion 
found on our radio links. Older sys- 
tems from companies such as Digital 
Equipment. Corporation and Sun 
Microsystems are often available on 
the used market at prices which are 
not too unreasonable. (Prices for 
upgrades and maintenance may still 
be painful.) In reality, this is almost 
certainly the easiest approach, parti- 
cularly when using a PC and NOS to 
run the radio connections. | hope to 
be able to.explore this alternative in 
the near future. 


o Conclusion 


Clearly, putting a UNIX system on 
the AMPRnet is not currently a trivial 
task. However, | hope I have presen- 
ted enough information so _ that 
someone with UNIX experience and a 
system can find an appropriate 
method to share their resources on 
the network. 


ESIX is a trademark of Everex 
Systems, Inc. UNIX is a registered 
trademark of AT&T. Ethernet is a 
registered trademark of Xerox. 


[1] Neuman, Clifford: “Packet 
Radio and IP for the Unix Operating 
System”, Sixth ARRL Computer Net- 
working Conference, 1987. 
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floppy, or perhaps a 5.25” 360k (I 
haven't installed a 1.2 meg five and 
a quarter drive yet) Drop it in the 
mail, it won't cost much and just 
think of all the others that will 
appreciate your efforts. My mailing 
address is: 


NETCPA c/o Rich Vitello - WA1EQU 
8 Denfeld Dr Westboro, MA 01581 


Conversely, if you have ideas of 
specific subjects, articles or you 
have a request, please write and let 
us know your thoughts. We wel- 
come your input. 


- THE NEXT NETCPA 
MEETING! - 


The next NETCPA meeting will be 
held Saturday June 8, 1991, the 
location is yet to be determined. 
Mark this date on your calender 
anyway so you can plan on attend- 
ing. It was suggested at the April 6th 
meeting that since we’re a New 
England Association that the meet- 
ing should be geographically spread 
around the New England area. All in 
attendance agreed, so we’re looking 
at possible meeting sites throughout 
the six state region. | will post the 
final meeting place in my 


“update@watequ” finger file. 
73, Rich 
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EFFECT OF TRANSMITTER TURN-ON TIME ON 
PACKET THROUGHPUT 


Charles R. Greene, wicg 115 
Aaron Avenue Bristol RI, 02809 


During recent discussions of the 
relative merits of higher speed 
modems, | mailed out some com- 
ments stating that the throughput to 
be expected for 4800 baud packet is 
not four times 1200 baud packet 
because the transmitter turn on time 
becomes an increasing percent of the 
total transmission time as the baud 
rate is increased. The actual increase 
is only two to three times for the 4800 
baud packet. This article amplifies 
these comments and provides an 
analysis of throughput for 1200, 4800 
and 9600 baud packet with typical 
transmitter turn on times. 


There is a good analysis of packet 
timing in a paper in the 4th Computer 
Networking Conference proceedings 
by David Engle, ke6ze 1. | have 
extended his analysis to 4800 and 
9600 baud and have simplified his 
presentation by considering the single 
case of: 


1) One way transmission and not 
the ACK. 


2) Simplex, direct connection in- 
stead of through switches. 


3) Packet length 256 bytes. 


| have left out times which are 
insignificant, for example, RF pro- 
pagation times of .03 sec; and | have 
lumped the processing times of the 
computer, TNC and receiver into “pro- 
cessing time.” This analysis, like the 
one by ke6ze, is for AX25 and not 
TCP/IP. 


Summarizing Reference 1.: 


The equivalent baud rate of packet 


transmissions is reduced from the 
nominal baud rate by the overhead 
time which includes the AX25 over- 
head, the processing time, the data 
receipt allowance and the transmitter 
turn on time. Transmission efficiency 
is the time to transmit the data divided 
by the total time which is the sum of 
the overhead time and the data trans- 
mission time. The AX25 overhead 
includes HDLC and AX25 sync, con- 
trol, address and checksum bytes. Its 
time varies as the data rate varies. 
The processing time is the time used 
by the computer, TNC, and receiver to 
process the packet; and it is approxi- 
mately 1 millisecond (ms). The data 
receipt allowance time is the 10 to 20 
ms added at the end of a transmission 
by the TNC. Transmitter turn on time 
is the time for the transmitter to 
stabilize its oscillator(s), to accomplish 
T/R switching and to come up to 
power. This time is in the order of 200 
to 300 ms for older, solid state crystal 
controlled rigs. Synthesized rigs 
require additional time for the phase 
lock loop to acquire the transmit 
frequency which may be as long as 
500 ms. The TNC turn on time is on 
the order of 50 ms, but this time is 
usually masked by the transmitter turn 
on time, so it is not included in this 
analysis. 


The results of the timing analysis 
are presented in table 1 for baud 
rates of 1200, 4800 and 9600, all for 
256 bytes of data (assuming 3% bit 
stuffing). 


The transmission efficiency is the 
transmission time for 256 bytes divi- 


ded by the total transmission time. It 
can be seen that the transmitter turn 
on time is the longest overhead factor, 
particularly at the higher speeds. 


Packet Transmission Analysis (All 
times in milliseconds) 


Baud Rate 1200 4800 9600 

AX25 overhead 133 33 17 

Processing 1 1 1 

time 

Data receipt 15 15 15 

allowance 

Transmitter turn SH 250" 290 

ontime = «= 

Total overhead 399 299 283 

Transmission 1758 440 219 

TNe@OR256 a5h5 on «lays! 

bytes 

Total time 2157 739 502 

Transmission 

efficiency 82% 60% 44% 
Table 1 


The above analysis was made 
assuming a transmitter turn on time of 
250 ms. | have an Azden synthesized 
transceiver which needs 65 (650 ms) 
for param 1 in the autoexec.net file to 
avoid losing synch bits at the start of 
each transmission. Many TCPers are 
using 50 (500 ms) for param 1. | use 
an old Motorola MICOR transceiver at 
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switch.wicg-9 on 144.91 Mhz and 
another on 449.125 Mhz. | plan to 
modify the UHF MICOR to leave its 
two oscillators on all the time and key 
the exciter and also reduce the pro- 
gramed time delay between receive 
and transmit to attain a transmitter 
turn on time of 100 ms or maybe even 
50 ms. 


Table 2 shows the effect of the 
longer and shorter transmitter turn 
on times on the effective baud rate 
(the transmission efficiency times 

the nominal baud rate). 


This table includes the best, 
average and worst conditions which 
can generally be expected. 


Effective Baud Rates With Typical 
Transmitter Turn on Times 


Nominal Baud 1200 4800 9600 
Rate 


Turn on Time, ms_ Transmitter 


Effective Baud Rate 


250 (Xtalrig 978 2858 4188 


with relays) 


500 (Usual 
TCPer’s 
settings) 


650 (w1cg’s 
Azden) 


50 (Best rate 
on MICOR?) 


8/6 = 219522796 


825 1854 2331 


1078 3918 6962 


Table 2 


The table shows how poorly our 
FM voice rigs preform for 4800 and 
9600 baud data. It is interesting to 
note that in some cases_ higher 
throughput can be obtained by reduc- 
ing the transmitter turn on time and 
staying at the same baud rate. 
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Another way to increase trans- 
mission efficiency is to increase the 
packet length so that the transmitter 
turn on time is a smaller percentage 
of the total time. However, a point of 
diminishing returns is reached 
because longer packets have a hig- 
her probability of errors, given the 
same data rate and signal to noise 
ratio, and will require more repeats. 
But increasing the packet length can 
be used to increase the throughput 
between two stations with mutually 
strong received signals and should 
be considered on a case by case 
basis. 


What to do? We should push the 
manufacturers to design FM trans- 
ceivers which can be used with the 
higher speed packet modems. It’s 
within the state of the art -look at HF 
full break in CW transceivers. In 
addition to shorter transmitter turn 
on times, they should provide rear 
panel connections to the xtal oscilla- 
tor and discriminator for connection 
to 4800 and higher baud modems. 
While they are at it, they should 
provide switchable band widths of 
15 and 100 Khz, because who says 
we will be satisfied with 9600 baud? 
Meanwhile, scrounge your flea mar- 
kets for used xtal transceivers or 
buy a old commercial one. 


Reference: 


1. David Engle, KE6ZE, “Packet 
Radio Timing Considerations,” 
ARRL Amateur Radio Computer . 


Networking Conferences 1-4, Ameri- 
can Radio Relay League, Newington 
CT, 1985, p 4.25. 


Update: Services Available 
on TCP/IP 


by Charlie Ross, NC1N 


In the September/October issue of 
the TCPer, we provided an_ initial 
listing of the “services” available on 


our New England network. The article 
also ran in the BCS newsletter, “The 
Wireless Bitstream,” and got picked 
up by the ARRL’s QEX/Gateway... 
thought the latter caused some under- 
standable confusion by those not on 
the New England net.... This month, 
we provide you with an update. To 
save space, we'll just provide the 
changes here... but you can always 
find the most recent version in the 
“services” directory of the wb6nil ser- 
ver. 


HIGHLIGHT OF 
CHANGES: 


With Rich, WA1EQU’s rejoining the 
network late last fall, the “update” 
finger service has moved back to his 
node from its temporary home at 
KA8SCP... but Terry has added a 
number of interesting finger and FTP 
services in its place! Mike, WA1PTC 
has an interesting SMTP server that 
takes an entire article to describe... 
(possibly elsewhere in this issue if 
space permits... else check wb6nil). 
K8LT’s experimental mail gateway 
between Usenet and the Amprnet is 
down, except for the TCP-Group dis- 
tribution which he still maintains. 


The big news in the past few 
months has been the installation of a 
hard disk at wb6nil, and the sub- 
sequent establishment of a file server 
there. 


And there’s more--see the new 
listings below for details. 


“ANONYMOUS” FTP FILE 
SERVERS 


Host Name: wailou.ampr.org 
Sysop: Stan Horzepa, WA1LOU 


For info, contact: 
wallou@wailou.ampr.org 


Stan has on-line copies of his 
recent ARRL packet radio columns- 
-Packet Perspective (from QST) and 
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_ Gateway (from QEX). He also plans to 
add public domain Macintosh ham 


_ radio software in the near future. 


Host Name: kalas.ampr.org 
Sysop: Al Bolduc, KA1AS 


For info, contact: 
kalas@ka1as.ampr.org 


KA1AS has a large amount of 
information available for ftp. In particu- 
lar, Al maintains both the TCP-Group 
Digests and the RFCs. TCP-Group 
Digest is an Internet mail distribution 
used by NOS and NET developers. 
RFCs (Requests for Comments) serve 
as the “specs” for the various pro- 
tocols in the TCP/IP suite. 


Host Name: ka8scp.ampr.org 
Sysop: Terry Stader, KA8SCP 


For info, contact: 
ka8scp@ka8scp.ampr.org 


Terry’s public folder contains a 
variety of files.... the most recent 
AMSAT and ARRL news, propagation 
bulletins as well as Sweeden Calling 
DX (SCDX) newsletters will be posted 
there as they become available. There 
is a whole collection of data about the 


Armed Forces of each of the countries 


involved with the Middle East crisis in 
the MidEast directory. Many other files 
of interest... Massachusetts public 
safety freqs as well as an Introduction 
to Shortwave Listening. Please feel 
free to send Terry mail about the 
worthiness of this section. 


Terry also has many Macintosh 
files and programs. Most of the Macin- 
tosh files will be compressed by Stuffit 
(“.SIT” suffix) or Compactor (‘“.cpt” 
suffix) so that you can transfer the 
smallest possible file. 


Host Name: wb6nil.ampr.org 
Sysop: Don Hughes, KA1MF 


For info, contact: 
kaimf@ka1mf.ampr.org 


Don is the EMA/CMA IP address 
coordinator and maintains the current 
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HOSTS and DOMAIN files at all times 
in the \public directory at the wb6nil 
switch. To accomodate various user 
systems, Don maintains these files in 
both ASCII and ZIP formats. (ZIP files 
are significantly compressed and 
therefore transfer faster than the 
ASCII version.) In addition, there are a 
number of TCP/IP documentation files 
available and usually one or more 
versions of NET and NOS. 


Host Name: walequ.ampr.org 
Sysop: Rich Vitello, WA1EQU 


For info, contact: 
walequ@wailequ.ampr.org 


Rich maintains a number of files on 
his system, among them the _ info 
published daily on the Internet's TCP- 
Group distribution. Rich has this data, 
in his \public\news directory, going 
back 3.5 years! If you want to get a 
perspective on how NOS and NET 
evolved, it makes for very interesting 
reading. 


Rich has a separate directory for 
software for each type of PC for which 
KA9Q software is available. Look for 
the IBM NOS & NET subdirectories, 
as well as Amiga, MAC, Atari, and 
MSYS and UNIX. (The MAC subdirec- 
tory just has “where-to-get-it” informa- 
tion.) 


But, there’s more: Rich also main- 
tains a “PROMS” subdiectory which 
has the actual prom kiss codes for 
both the tnci & tnc2. In his MISC 
sub-directory you'll find everything 
from radio mods to a zipped up file of 
TCP/IP experiments/conversations he 
conducted on HF! And he also has a 
lot of NE TCPer files and back issues 
available. 


This all totals more than 5 Mega- 
bytes dedicated to TCP/IP! 


SERVICES AVAILABLE THROUGH 
SMTP 


Host Name: w1cg.ampr.org 


Sysop: Charlie “Chas” Greene, 
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W1CG 


W1CG maintains a mailer for 
Rhode Island stations. Anyone want- 
ing to mail a message to a RI station 
with an IP address, send the mail to: 
call@wicg.ampr.org. W1CG is on the 
air 24 hrs, and his system will keep 
the message until it can be deliveried. 


Host Name: watequ.ampr.org 
Sysop: Rich Vitello, WA1EQU 


Rich maintains the “allne” mail 
distribution list. To send mail to all 
active TCPers on the net, address it to 
“allne@watequ”. 


Host Name: wa1ptc.ampr.org 
Sysop: Mike Staines, WA1PTC 


Send SMTP Mail To: ser- 
ver@waiptc.ampr.org 


Mike has set up an automated 
server running on his Amiga system. 
He’s provided a complete write-up 
which, due to its length, is stored as a 
separate file. For more info, download 
“waiptc.txt” from wb6nil. 


FINGER SERVICES 
Host Name: waiequ.ampr.org 
Sysop: Rich Vitello, WA1EQU 


For info, contact: 
walequ@waiequ.ampr.org 


Rich maintains the Eastern/Central 
Massachusetts ‘Update’ service. 
Finger “update@waiequ” to get a 
current, on-line “newsletter” of area 
TCP/IP news and events. 


Host Name: ka8scp.ampr.org 
Sysop: Terry Stader, KA8SCP 


For info, contact: 
ka8scp@ka8scp.ampr.org 


Terry maintains the latest news 
from AMSAT available as a finger file. 
Finger “amsat@ka8scp”. 


+ 


A Note from the Editor. 


You will notice that this issue is two 
pages less than our previous issues. 
Why is that you may ask? For the 
simple lack of people contributing 
articles to your newsletter. Again who 
are these people who aren't contribut- 
ing? Well when was the last time you 
sent in an article? Have you ever sent 
in one? 


Remember this isn’t a professional 
newsletter we have going here. This 
is a group effort, and if only a few 
people are always putting out all the 
effort you can be sure that the TCPer 
will not be getting any and bigger and 
we just might end up getting smaller. 


a SED eS 


N E TCPer 
- PO BOX 268 
Francestown, NH 


03043 


It doesn’t take a Mark Twain to 
write something for a TCP/IP article. 
I'll say again if you would like to send 
us an article, please do. They can 
either be sent via SMTP mail, IBM 
floppy disk any size, or via Com- 
puserve. 


Thank you for your support. 


nigcr@nigcr & Compuserve 
73320,2317. Mailing address below. 


73 from mark niger. 


= ; LIC AIT 
Stroh N&GNJ 


wu 


WAVY 


